Understanding Events/Alerts/Incidents

#1

Hello,

We have some current automation posting to the enqueue endpoint to trigger alerts for our on-call individuals. These posts include the routing keys created by setting up an integration for each service using the Microsoft Flow integration. We’re currently migrating our workflows to another RPA tool instead of Flow and have rebuilt the functionality, but curious if there’s a generic API key.

Is there a recommended/best practice method of triggering events/alerts via REST API for each service directory? We looked into the OAuth method, but this does not seem to be useful for events/alerts.

#2

Hello @kevin.clement!

The recommend way to create alerts in PagerDuty is to send events to the Events API and use the service integration key for proper redirection to the correct service. So you are doing it correctly.

You have an option to use REST APIs with a global integration key but that doesn’t allow you to send events to PagerDuty, it will only allow you to create incidents directly. This will also require you to provide the service id in the request payload to indicate in which service the incident will be associated to. This is not effective and I wouldn’t recommend it unless you have a strong reason for it.

Let me know if this helps.

#3

Thanks @tiago.barbosa.

Following up on some general knowledge, when posting an event to events v2 API, how can you then reference that alert/incident created from said event?

We get a dedup key back in the response, but not sure how to utilize that.

#4

Hi @kevin.clement!

When using the Events v2 API you either send Alert events or Change events. Alert Events create alerts in PagerDuty and therefore you can get the information on the events sent either that triggered the alert and potentially and incident by using the Incidents API. Still there is no reference to the event itself, as the event information will be added to the alert on creation time.

The dedup key you get when you send events to PagerDuty is the alert deduplication key. This is pretty helpful as it allows you to instruct PagerDuty to group events into the same alert. If you send multiple events with the same dedup key they get grouped into the same alert and target incident.

It is important to have this in mind when building a custom integration with PagerDuty through its APIs. I would recommend you to take a look at this page if you haven’t done so to understand the lifecycle of an event sent to PagerDuty.

#5

Hey @tiago.barbosa,

Looking into the OAuth endpoints here and noticed some discrepancy in the documentation for authorization.

The following shows Preamble with “Bearer”: https://developer.pagerduty.com/docs/e518101fde5f3-obtaining-an-app-o-auth-token

While the following shows Preamble with “Token”: https://developer.pagerduty.com/api-reference/3a6b910f11050-list-all-of-the-on-calls

Do we know if this is a discrepancy or not?

#6

Hi @kevin.clement!
Good catch! If you use Scoped OAuth with our APIs, you need to use the Bearer keyword on the Authorization header. If you go to our API reference you’ll see the OAuth permissions you need to have so you can call a specific endpoint and operation.

image
image.png1168Ă—688 60.9 KB

The discrepancy you are referring to is because our API reference page currently only supports the Token token="…" approach. I hope that makes sense.

#7

Hmm, slightly confused as using the Token preamble seems to have worked on the oncalls endpoint just now.